The present embodiments relate to computer networks and are more particularly directed to a network with MAC table overflow protection.
Ethernet networks have found favor in many applications in the networking industry and for various reasons. For example, Ethernet is a widely used and cost effective medium, with numerous interfaces and speed capability up to the 10+ Gbps range. Ethernet networks may be used in applications that are incorporated at a single location by a single entity such as a company or the like, or the entity as an alternative may couple various local area networks (“LANs”) together to form a larger network, sometimes referred to as a wide area network (“WAN”). Still further, Ethernet technology is also often used to form a network sometimes referred to as a Metro Ethernet Network (“MEN”), which is generally a publicly accessible network that is often affiliated with a metropolitan area—hence, the term “Metro” Ethernet. A MEN provides a so-called Metro domain, typically under the control of a single administrator or manager, such as an Internet Service Provider (“ISP”). A MEN is typically used to connect between an access network and a core network. The access network often includes edge nodes that operate as bridges to private or end users, that is, customer nodes, making connectivity to the network. The core network is used to connect to other Metro Ethernet Networks and it provides primarily a frame switching function.
Ethernet networks typically include a number of bridges, sometimes also referred to by other names such as switches. A bridge typically operates to receive a frame, which is sometimes referred to by other names such as a packet or message, which in any event includes a portion, such as a header, with both a source and destination address. The frame may include other information, such as a payload or data that is being communicated from the device at the source address to the device at the destination address. The bridge receives this frame at a port from that source and forwards it via a port to that destination, where both the source and the destination may be another bridge or a user or other node in the Ethernet network. The bridge performs its routing function by developing (or “learning”) a table of each address connected and corresponding to each of its ports and then consulting its table later so as to forward a frame to the desired address by forwarding the frame out the port that is indicated in the table as connected to the destination having that address. The table so introduced here is referred to in this document as a MAC address forwarding table, where MAC is an abbreviation for Media Access Control, and each MAC address is a hardware address that uniquely identifies its corresponding piece of hardware in a network. Specifically, in IEEE 802 networks, the Data Link Control (“DLC”) layer of the OSI Reference Model is divided into two sublayers, namely: (i) the Logical Link Control (“LLC”) layer; and (ii) MAC layer. The MAC layer interfaces directly with the network medium (i.e., the physical layer, or layer 1 in the OSI). Consequently, each different connection to the network medium requires a different MAC address. Ultimately, when the bridge receives a frame, it reads the destination MAC address from the header information in the frame, establishes a temporary connection between the source and destination ports, forwards the frame out its destination port, and then terminates the connection.
An unfortunate development in the heavy use of networks in contemporary computing has been the many efforts of wrongdoers to either cause trouble to the operation of the network or to gain unauthorized access to network resources. In the context of Ethernet networks, one malicious effort has been for a user to connect to the network and then flood a bridge with an unusually large number of frames, thereby adding different and unknown MAC addresses. When the bridge receives each frame, the bridge examines its MAC address forwarding table to determine if the table has the source MAC address in that frame recorded in that forwarding table. If the address is not so recorded, the table stores the address and associates it with the port that received the frame that carried that source address—thus, the source address is thereafter associated with a port on the bridge. Consequently, when a subsequent frame (or frames) is received with a destination address that matches an already-stored MAC address in the forwarding table, the bridge forwards the frame along the port associated with that address. From the preceding, therefore, note that the bridge initially stores into its forwarding table an entry for each source address not already stored in the table. As the number of such unknown source addresses of this sort grows, eventually the storage for them becomes full. At this point, however, and per the prior art, if the bridge receives a frame with a destination address that is not in the already-full forwarding table, then the bridge often “broadcasts” each such frame, meaning it communicates the frame out of all of its ports (other than the port on which it received the frame), with the expectation that the destination will receive the frame and respond to the broadcasting bridge with a confirmation, thereby permitting the bridge to update its MAC address forwarding table so that thereafter it has an entry that associates the port that received the confirmation with that destination MAC address. However, note that this approach has limitations, which are particularly victimized by the wrongdoer who floods the bridge per the prior art. For example, the MAC table has limited space. As another example, the MAC address forwarding table associates a timeout window with each stored MAC address, so that if there is no activity for the respective address during the timeout period, then that address is removed from the MAC table. Given these limitations, a wrongdoer may send thousands of different MAC addresses to a same bridge in a relatively short time period. Due to its size limitations, the MAC address forwarding table of the bridge will reach its address limits and if broadcasting will add a large amount of traffic to the network. Moreover, once the MAC address forwarding table fills, the bridge having that table no longer accepts new MAC addresses, that is, it broadcasts all incoming traffic with unknown MAC addresses to the ports within the VLAN defined by the frame. As a result, quickly the bridge is overwhelmed and it fails to perform its bridging functionality while also starting to drop frames from other sources. Thus, the bridge and possibly the network as a whole are stifled by this attack.
Two approaches have been attempted in the prior art to deal with the above-discussed principles and bridge limitations. In a first approach, MAC addresses are statically changed in the bridge MAC address forwarding table. In this approach, the MAC address forwarding table is manually established, and when new frames with not-yet-included MAC destination addresses are received by the bridge, they are dropped and the table is therefore not later updated with what would be a response to a broadcast of that frame. However, since the dropped frames are not broadcast by the bridge, there is a reduced chance of burdening the network with these frames. In a second approach, a MAC-based authentication is employed each time a node joins the network or is powered on. In this approach, when a MAC address entity joins the network or is powered on, it issues what is sometimes referred to as a registration frame so that the frame may be received by a bridge and the bridge may update its MAC address accordingly.
The prior art approaches discussed above may reduce the chance for a bridge to be overburdened by flooding it with MAC frames, but there are also drawbacks to these approaches as may be ascertained by one skilled in the art. As a drawback example of the first approach, legitimate frames may be received by the bridge, but if they include a destination MAC address that is not already in the bridge table, those frames will be dropped and therefore denied service by the network. As a drawback example of the second approach, multiple instances of a registration are required in that a device may be periodically powered off and on, and it also permits a wrongdoer to flood the network and its bridges with numerous registration frames. Given the above, a need has arisen to address the drawbacks of the prior art as is achieved by the preferred embodiments as further detailed below.